Video data processing apparatus

ABSTRACT

A video data processing apparatus including a file creation unit that creates a file including video packets that is received from a video source, an index creation unit that creates an index file including a sequence number and offset position information, indicating a position in the created file, of each of the video packets included in the created file, and a complementary data creation unit that creates, when there is a loss of a video packet in the created file, complementary data for complementing the loss of the video packet, based on the index file of the created file and an index file of another file including video packets received from the video source by a path different from a path of the video packets included in the created file.

CROSS-REFERENCE TO RELATED APPLICATION

This application is based upon and claims the benefit of priority of theprior Japanese Patent Application No. 2015-066658, filed on Mar. 27,2015, the entire contents of which are incorporated herein by reference.

FIELD

The present invention relates to a video data processing apparatus, avideo data processing system, a video data processing method, and avideo data processing program for accumulating video data.

BACKGROUND

For example, a broadcast station has fixed-point observation cameras,such as so-called weather cameras, installed at various locations. Avideo of each fixed-point observation camera is transmitted to a datacenter by streaming delivery, and is accumulated in the data center. Forexample, in the event of natural disasters such as earthquakes, tsunamisand eruptions, or at the time of investigation of a crime or the like,VOD (Video on Demand) distribution is performed by reading video data ofa specified time from video data, of a fixed-point observation camera,accumulated in the data center. In many cases, reliability of video dataof a fixed-point observation camera is secured by the data being held bya plurality of storage devices according to a redundant configuration ofthe system.

FIG. 1 is a diagram illustrating an example of a video data accumulationsystem. A video data accumulation system 100 is an example where aredundant configuration is adopted by a data center, and where videodata is held by different storage devices. The video data accumulationsystem 100 includes a data center 61 and an encoder 50 that areconnected over the Internet. For example, the encoder 50 is afixed-point observation camera. For example, the encoder 50 encodesvideo data by MPEG (Moving Picture Experts Group), and successivelytransmits the data to the data center 61 by using RTP (Real-timeTransport Protocol). The RTP is a protocol for transmitting audio andvideo in a real time. The flow of data that is streamed from apredetermined source to a predetermined destination is called a stream.

The data center 61 is a data center of a broadcast station, for example.The data center 61 includes a relay server 70, an accumulation server A,an accumulation server B, a file server A, and a file server B.Additionally, in the case of not distinguishing between the accumulationservers A and B, they will be written as “accumulation server(s) 1”. Inthe case of not distinguishing between the file servers A and B, theywill be written as “file server(s) 2”. The accumulation server A and theaccumulation server B are servers installed at different locations. Theaccumulation servers A and B may use a common file server 2 or differentfile servers 2.

According to the video data accumulation system 100 illustrated in FIG.1, there is one path between the encoder 50 and the data center 61, andvideo data is transmitted along this one path. The video data isduplicated, in the data center 61, by the relay server 70, and istransferred to each of the accumulation servers A and B. Theaccumulation servers A and B accumulate, as files, the video data in thefile servers A and B, respectively. Files of the video data received bythe accumulation servers A and B are illustrated in FIG. 1 as files Aand B.

FIG. 2 is a diagram illustrating an example of the video dataaccumulation system. A video data accumulation system 200 is aconfiguration where the paths from an encoder to a data center andaccumulation servers are made redundant.

The video data accumulation system 200 includes a data center 62 and anencoder 50 that are connected over the Internet. The data center 62includes an accumulation server A and an accumulation server B. Theaccumulation servers A and B are installed at different locations.

According to the video data accumulation system 200, the encoder 50 hasdifferent paths for the accumulation servers A and B, and transmits thesame video data along the respective paths. The accumulation servers Aand B accumulate the received video data in the file servers A and B asfiles A and B, respectively.

PATENT DOCUMENT

-   [Patent document 1] National Publication of International Patent    Application No. 2009-534928-   [Patent document 2] Japanese Patent Laid-Open No. 2006-5942

However, the redundant configurations of the video data accumulationsystems illustrated in FIGS. 1 and 2 have the following problem. FIG. 3is a diagram illustrating an example of a problem of a redundantconfiguration of a video data accumulation system. In FIG. 3, theaccumulation servers A and B in the data center 61, 62, and a file A inthe file server A and a file B in the file server B are extracted andillustrated.

The RTP, which is used for transmission of video data, uses UDP (UserDatagram Protocol) as a protocol of a transport layer, and the UDP is aprotocol which does not guarantee arrival. Accordingly, an RTP packet ofvideo data may possibly go missing due to packet loss duringtransmission. Packet loss is one cause of reduced video quality.

Accordingly, due to the influence of packet loss during transmission,the video data included in the files A and B is not necessarily the sameas the original video data transmitted from the encoder 50. Also, sincethe path of video data is different for the file A and the file B, thepacket that is lost due to packet loss is possibly different, and thefile A and the file B are not necessarily the same.

In the example illustrated in FIG. 3, RTP packets #3 and #4 are lost forthe file A. For the file B, RTP packets #2 and #5 are lost. That is,both the file A and the file B are different from the original videodata transmitted by the encoder 50. Also, the file A and the file B aredifferent from each other.

Since encoded video data is transmitted from the encoder 50, encodeddata is included in the files A and B. At the time of determination ofthe video quality of the files A and B, the encoded data is decoded, andthus the processing load regarding the accumulated data possibly becomesgreat. Accordingly, it is difficult to determine which of the files Aand B is the video data of higher quality. Therefore, even if the file Bis the file of higher video quality with less lost packets, the file Ais possibly read depending on the pre-setting.

SUMMARY

According to an aspect, a video data processing apparatus includes afile creation unit that creates a file including video packets receivedfrom a video source, an index creation unit that creates an index fileincluding a sequence number and offset position information, indicatinga position in the created file, of each of the video packets included inthe created file, and a complementary data creation unit that creates,when there is a loss of a video packet in the created file,complementary data for complementing the loss of the video packet, basedon the index file of the created file and an index file of another fileincluding video packets received from the video source by a pathdifferent from a path of the video packets included in the created file.

The object and advantages of the invention will be realized and attainedby means of the elements and combinations particularly pointed out inthe claims.

It is to be understood that both the foregoing general description andthe following detailed description are exemplary and explanatory and arenot restrictive of the invention.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a diagram illustrating an example of a video data accumulationsystem;

FIG. 2 is a diagram illustrating an example of the video dataaccumulation system;

FIG. 3 is a diagram illustrating an example of a problem of a redundantconfiguration of the video data accumulation system;

FIG. 4 is a diagram illustrating an example hardware configuration of anaccumulation server;

FIG. 5 is a diagram illustrating an example functional configuration ofthe accumulation server;

FIG. 6 is a diagram illustrating a structure of an RTP packet fortransmitting video data;

FIG. 7 is a diagram illustrating an example of video file creationprocessing by an accumulation unit;

FIG. 8 is a diagram illustrating an example structure of an index file;

FIG. 9 is a diagram illustrating examples of processing by acomplementing processing unit and a delivery processing unit;

FIG. 10 is an example of a flow chart of processing by the accumulationunit of the accumulation server;

FIG. 11 is an example of a flow chart of processing by an intermediateprocessing unit of the accumulation server;

FIG. 12 is an example of a flow chart of processing by the complementingprocessing unit of the accumulation server;

FIG. 13A is an example of a flow chart of processing by the deliveryprocessing unit of the accumulation server;

FIG. 13B is an example of a flow chart of processing by the deliveryprocessing unit of the accumulation server; and

FIG. 14 is an example of a flow chart of processing by a deletionprocessing unit of the accumulation server.

DESCRIPTION OF EMBODIMENT

Hereinafter, an embodiment of the present invention will be describedwith reference to the drawings. The configuration of the embodimentdescribed below is merely an example, and the present invention is notlimited to the configuration of the embodiment.

First Embodiment

A system configuration of a video data accumulation system may be thatof the video data accumulation system illustrated in FIG. 1 or 2, forexample. In the first embodiment, the video data accumulation system 200illustrated in FIG. 2 is assumed. An encoder 50 is, for example, afixed-point observation camera, and is operating at all times. Also, theencoder 50 performs streaming delivery to accumulation servers A and B.In the first embodiment, streaming delivery means that video datacaptured by a fixed-point observation camera or the like is encoded bythe encoder 50, and that transmission of the encoded data is performedat the time point of the encoded data being transferred to the hard diskor the like of the encoder 50.

For example, the accumulation servers A and B create respective files Aand B including video packets received, through different paths, fromone encoder 50 by streaming delivery. Sequence numbers are added to thevideo packets by the encoder 50. The accumulation servers A, B generate,for the respective files A, B, index files including the sequencenumbers of the video packets included in the files A, B, and offsetposition information indicating the position, inside the files A, B,from the beginning.

The accumulation servers A, B specify, based on the index files of thefiles A, B, video packets in the files A, B which have been lost, basedon the portions where the sequence numbers are not continuous. In thefollowing, a video packet which has been lost will be simply referred toas a lost packet. The accumulation servers A, B acquire the offsetposition information of the lost packets in the files A, B from theindex files of the files B, A, and acquire the video packetscorresponding to the acquired offset position information from the filesB, A.

The accumulation servers A, B create complementary files A-1, B-1 of therespective files A, B by the video packets, corresponding to the lostpackets, acquired from the files B, A.

Accordingly, regardless of which of the files A and B is read, theoriginal video data transmitted from the encoder 50 may be reproduced bythe lost packet being read from the complementary file A-1 or B-1.

In the first embodiment, the encoder 50 is assumed to encode video databy using MPEG. Also, the encoder 50 is assumed to transmit video data byusing RTP.

The encoder 50 is an example of a “video source”. The accumulationservers A and B are examples of a “video data processing apparatus”. Thevideo data accumulation systems 100 and 200 are examples of a “videodata processing system”.

<Device Configuration>

FIG. 4 is a diagram illustrating an example hardware configuration of anaccumulation server 1. The accumulation server 1 is a dedicated orgeneral-purpose computer, for example. The accumulation server 1includes a CPU (Central Processing Unit) 101, a main storage device 102,an auxiliary storage device 103, and a network interface 104. Also,these are electrically interconnected by a bus 105.

The auxiliary storage device 103 stores various programs, and data to beused by the CPU 101 at the time of execution of each program. Theauxiliary storage device 103 is a non-volatile memory such as a harddisk drive, for example. The auxiliary storage device 103 holds anoperating system (OS), a video data processing program 103P, and othervarious application programs, for example. The video data processingprogram 103P is a program for acquiring a lost packet of a file fromanother file, and for creating complementary data.

The main storage device 102 provides the CPU 101 with a work area and astorage area for loading a program stored in the auxiliary storagedevice 103, or is used as a buffer. The main storage device 102 includesa semiconductor memory such as a RAM (Random Access Memory), forexample.

The CPU 101 performs various processes by loading, on the main storagedevice 102, and executing the OS and various application programs heldby the auxiliary storage device 103. The number of CPUs 101 is notlimited to one, and a plurality of CPUs 101 may be provided.

The network interface 104 is an interface for performing input/output ofa signal to/from a network. The network interface 104 includes aninterface for connecting to a wired network, and an interface forconnecting to a wireless network. In the case of connecting to a wirednetwork, the network interface 104 is a light signal circuit, or an NIC(Network Interface Card), for example. In the case of connecting to awireless network, the network interface 104 is a satellite signalreceiving circuit or the like. Data or the like received by the networkinterface 104 is output to the CPU 101.

Additionally, the hardware configuration of the accumulation server 1illustrated in FIG. 4 is merely an example and is not restrictive, andstructural elements may be omitted, replaced or added as appropriateaccording to the embodiment. For example, the accumulation server 1 mayinclude a removable recording medium drive device, and may execute aprogram recorded in a removable recording medium. The removablerecording medium is a recording medium such as an SD card, a mini SDcard, a micro SD card, a USB (Universal Serial Bus) flash memory, a CD(Compact Disc), a DVD (Digital Versatile Disc), a Blu-ray (registeredtrademark) Disc, or a flash memory card.

FIG. 5 is a diagram illustrating an example functional configuration ofthe accumulation server 1. As the functional configuration, theaccumulation server 1 includes an accumulation unit 11, an intermediateprocessing unit 12, a complementing processing unit 13, a deliveryprocessing unit 14, and a deletion processing unit 15. The accumulationunit 11, the intermediate processing unit 12, the complementingprocessing unit 13, the delivery processing unit 14, and the deletionprocessing unit 15 are a functional configuration achieved by the CPU101 executing a video data processing program 103P.

The accumulation server 1 is connected to a file server 2. The fileserver 2 is a server for executing a file sharing protocol of a NAS(Network Attached Storage) or a CIFS (Common Internet File System), forexample.

The accumulation unit 11 continuously receives RTP packets from theencoder 50. The accumulation unit 11 divides the received video databased on timestamps added to the video data into predetermined timelength units from a predetermined reference time, and takes the videodata included in a divided predetermined time length as one video file.The predetermined time length may be freely set by an administrator ofthe data center 62 between 30 minutes to one day, for example. A videofile has an amount of data corresponding to the time length of thepredetermined time slot at the maximum. The video file is stored in thefile server 2. The accumulation unit 11 is an example of a “filecreation unit”.

The accumulation unit 11 performs hash calculation of the video file,and creates hash data. Although not limited, hash calculation is SHA1(Secure Hash Algorithm 1), MD5 (Message Digest Algorithm 5) or the like,for example. The accumulation unit 11 stores the hash data in the fileserver 2 by associating the same with the corresponding video file. Theaccumulation unit 11 is an example of a “hash data creation unit”.

The accumulation unit 11 creates an index file for the video file.Details of the index file will be given later. The accumulation unit 11stores the index file in the file server 2 by associating the same withthe corresponding video file. The accumulation unit 11 is an example ofan “index creation unit”.

The intermediate processing unit 12 acquires hash data of a target videofile from the file server 2. Also, the intermediate processing unit 12acquires, from the corresponding file server 2, hash data of a videofile created by another device, the video file being redundant data ofthe target video file. For example, the intermediate processing unit 12of the accumulation server A in FIG. 2 acquires hash data of a file Afrom the file server A, and acquires, from the file server B, hash dataof a file B created by the accumulation server B.

The intermediate processing unit 12 compares the two pieces of hash dataacquired. For example, in the case where no packet is lost for the fileA and the file B in FIG. 2, the pieces of hash data of the file A andfile B coincide with each other. However, in the case where packet lossoccurs during transmission of video packets included in the file A andthe file B in FIG. 2, the file A and the file B do not coincide witheach other, and the pieces of hash data of the file A and the file B donot coincide with each other.

Accordingly, in the case where two pieces of hash data acquired do notcoincide with each other, the intermediate processing unit 12 determinesthat there is possibly a missing packet in the video file its ownerdevice has created, and invokes the complementing processing unit 13. Inthe case where two pieces of hash data acquired coincide with eachother, the intermediate processing unit 12 determines that no packet ismissing in the video file its owner device has created, and does notinvoke the complementing processing unit 13. The intermediate processingunit 12 is an example of a “comparison unit”.

Additionally, there is a possibility that the packets that got lostduring transmission of video packets included in the file A and the fileB in FIG. 2 coincide with each other, and that the hash data of the fileA and the hash data of the file B coincide with each other. If thepackets that got lost during transmission of video packets included inthe file A and the file B coincide with each other, it is not possibleto complement the lost packet of one file by the other file. There isalso a possibility that, although the packets that got lost duringtransmission of video packets included in the file A and the file B aredifferent, the hash data of the file A and the hash data of the file Bcoincide with each other. Since the possibility of such an eventhappening is very low, such a case is not considered in the firstembodiment.

When invoked by the intermediate processing unit 12, the complementingprocessing unit 13 creates a complementary file for the lost packet ofthe video file its owner device has created, based on the index file ofthe video file its owner device has created and the index file of thevideo file created by another device. Specifically, the complementingprocessing unit 13 acquires a video packet corresponding to the lostpacket of the video file its owner device has created, from the videofile created by the other device. The complementing processing unit 13creates, from the acquired video packet, a complementary file, which isa file different from the corresponding video file. The complementingprocessing unit 13 associates the complementary file with thecorresponding video file, and stores the complementary file in the fileserver 2. The complementing processing unit 13 is an example of a“complementary data creation unit”.

When a delivery request for a video file is received, the deliveryprocessing unit 14 specifies the position, in the video file, of a videopacket at the time specified by the delivery request based on the indexfile, and starts delivery from the specified video packet. The deliveryprocessing unit 14 reads a video packet, in the video file,corresponding to a lost packet from a corresponding complementary file.The delivery processing unit 14 is an example of a “delivery unit”.

Of the video file the owner device of the deletion processing unit 15has created and the video file the other device has created, which isthe redundant data of the aforementioned video file, the deletionprocessing unit 15 deletes the video file of poorer video quality, andits index file, hash data and complementary file. Note, the deletionprocessing unit 15 is provided to one of the accumulation servers A andB which is set as a master, and is not provided to an accumulationserver which is not a master. In the first embodiment, whether the videoquality is higher or poorer is determined based on the number of timesof occurrence of continuous lost packets. The deletion processing unit15 is an example of a “deletion unit”.

The hardware configuration of the file server 2 is approximately thesame as the hardware configuration of the accumulation server 1, andincludes a CPU, a main storage device, an auxiliary storage device, anda network interface. The file server 2 reads and writes data of a fileor the like according to a request from the accumulation server 1.

The file server 2 may be installed at the same location as theaccumulation server 1, or may be installed at a different location. Aplurality of file servers 2 are installed at the data center 62, andwhich of the file server 2 is to be used by the accumulation server 1 isset by the administrator in advance.

According to the first embodiment, a video file, an index file, hashdata and a complementary file are stored, by the accumulation server 1,and held as a set in the auxiliary storage device of the file server 2.In the first embodiment, the video file, the index file, the hash dataand the complementary file are associated with one another by having acommon file name. In the case where video files are created in units oftime slots of a time length of one hour, the file name is added in sucha way as to indicate the date and the time slot of recording of thevideo, for example. Also, the video file, the index file, the hash dataand the complementary file have different extensions, and determinationof a file is enabled by the extension.

Incidentally, the video file, the index file, the hash data and thecomplementary file do not have to be associated with one another in theabove manner. Also, the method of adding a file name is not limited tothe above method.

FIG. 6 is a diagram illustrating a structure of an RTP packet fortransmitting video data. A plurality of TS (TranSport) packets arestored in a payload portion of an RTP packet. A TS packet is a packetthat is created by video data input from a fixed-point camera, forexample, being encoded by the encoder 50 by MPEG. A TS packet is anexample of a “video packet”.

The size of a TS packet is 188 bytes in the case of MPEG-2, for example.Also, in the case where a timestamp is added to a TS packet, the size ofthe TS packet is 192 bytes, and the packet is referred to as a TTS(Timestamped TS) packet. The timestamp of a TTS packet indicates thetime when the TTS packet was created by the encoder 50. In the firstembodiment, a TTS packet to which a timestamp is added by the encoder 50is assumed to be used. Hereinafter, a TS packet and a TTS packet arereferred to as TS packet(s) without being distinguished from each other.In the case where a TTS packet is to be distinguished from a TS packet,it will be written as a TTS packet.

An MTU (Maximum Transmission Unit) of an IP packet is 1500 bytes, andthus, theoretically, a maximum of seven TTS packets may be stored in oneRTP packet. Additionally, the upper limit of the number of TTS packetsto be stored in an RTP packet may be freely set by the administrator.

A timestamp is added to the beginning of a TS packet. One of pieces ofinformation included in the header of a TS packet is a sequence number.According to MPEG-2, the sequence number of a TS packet is indicated bya 4-byte continuity counter. According to the continuity counter, thevalue is incremented by one, and when the maximum value 16 (0×1111) isreached, the value returns to 0 (0×0000).

If one RTP packet is lost during transmission of video data, a pluralityof TS packets stored in the RTP packets are also lost. In the case wheresix TS packets are included in one RTP packet, if one RTP packet islost, six TS packets are lost. Accordingly, the sequence numbers of TSpackets preceding and following the lost packets in the video file willbe, for example, 0 and 7 with six numbers being skipped. In this manner,packet loss may be detected by the discontinuity in the sequencenumbers.

FIG. 7 is a diagram illustrating an example of video file creationprocessing by the accumulation unit 11. The accumulation unit 11includes a file output buffer 11M. The size of the file output buffer11M is a size allowing storage of TS packets of a predetermined timelength. For example, the size of the file output buffer 11M is a sizeallowing storage of TS packets amounting to 30 seconds.

When an RTP packet is received, the accumulation unit 11 stores the TSpackets stored in the payload portion of the RTP packet in the fileoutput buffer 11M in the order of the sequence number. When the fileoutput buffer 11M becomes full, the accumulation unit 11 adds the TSpackets stored in the file output buffer 11M to the end of a latestvideo file in the file server 2 in the order of the sequence number.When the size of the latest video file reaches the maximum time length,the accumulation unit 11 newly creates a video file, and thereafter, thenewly created video file is treated as the latest video file.

FIG. 8 is a diagram illustrating an example structure of the index file.The index file includes accumulation information and TS information.

The accumulation information is overall information about the video filecorresponding to the index file. For example, the accumulationinformation includes the number of TS packets included in the video filecorresponding to the index file, and the size of the video file. Thesize of a file included in the accumulation information is in units ofbytes.

The TS information is information about a TS packet included in thevideo file corresponding to the index file. One piece of TS informationis created for one TS packet. That is, the number of pieces of TSinformation present in the index file is equal to the number of TSpackets included in the corresponding video file. The TS informationincludes a TS time, a sequence number, an offset, and a timestamp, forexample.

The TS time included in the TS information is a reproduction start timeof the TS packet where the beginning of the video file corresponding tothe index file is taken as the base point. The TS time is in units ofmilliseconds, for example.

The sequence number included in the TS information is the value of thesequence number included in the header of the TS packet. The offsetincluded in the TS information is the number of bytes from the beginningof the video file corresponding to the index file to the TS packet.

The timestamp included in the TS information is the value of thetimestamp added to the beginning of the TS packet. In the case where theclock frequency is different between the encoder 50 and the accumulationserver 1, the value of the timestamp is converted into the unit of clockfrequency of the accumulation server 1.

The index file is created and updated by the accumulation unit 11 at thetime of writing of a TS packet in the video file in the file server 2.

FIG. 9 is a diagram illustrating examples of processing by thecomplementing processing unit 13 and the delivery processing unit 14.FIG. 9 illustrates an example of a case where the accumulation server Ain FIG. 2 complements a lost packet of the file A by using the file B.In FIG. 9, the sequence numbers of the TS packets are denoted as #1, #2and the like for the sake of convenience in the description.

The complementing processing unit 13 specifies a lost packet based onthe discontinuity in the sequence numbers of the TS packets in the indexfile of the file A. In the file A illustrated in FIG. 9, the TS packetfollowing a TS packet #2 is a TS packet #5, and the sequence numbers arediscontinuous. Accordingly, loss of TS packets #3 and #4 is specified.

The complementing processing unit 13 refers to the index file of thefile B, and determines whether the TS packets #3 and #4, which are thelost packets of the file A, are in the file B. In the exampleillustrated in FIG. 9, the TS packets #3 and #4 are present in the fileB. The complementing processing unit 13 acquires the offsets of the TSpackets #3 and #4 from the index file of the file B, and acquires the TSpackets #3 and #4 from the positions, in the file B, indicated by theoffsets.

The complementing processing unit 13 adds the TS packets #3 and #4acquired from the file B to a complementary file. Additionally, thecomplementing processing unit 13 includes a processing buffer, andstores, in the processing buffer, the TS packets acquired from the fileB for complementing the lost packets of the file A. When the processingbuffer becomes full, or when the complementing process for the targetvideo file is ended, the complementing processing unit 13 stores the TSpackets in the processing buffer in the complementary file.

In the case of delivering the file A, the delivery processing unit 14starts reading from a TS packet, in the file A, at a specified time in adelivery request. For example, if reading is started from the TS packet#1, the delivery processing unit 14 refers to the index file, detectsthat the TS packet #2 to be read next is in the file A, and reads the TSpacket #2 from the file A. Next, the delivery processing unit 14 refersto the index file, detects that the TS packet #3 to be read next is notin the file A, and reads the TS packet #3 from the complementary file.The TS packet #4 is also read from the complementary file in the samemanner.

In the case where the file A is to be complemented by inserting apacket, acquired from the file B, at the position of a lost packet ofthe file A, a process of rewriting the file A is to be performed, andthus the processing load on the accumulation server A possibly becomesgreat. By creating a complementary file separate from a video file, thefile A may be complemented by changing the read destination of a lostpacket to the complementary file, and thus the load on the accumulationserver 1 may be reduced compared to the process of rewriting the file A.

<Flow of Processing>

FIG. 10 is an example of a flow chart of processing by the accumulationunit 11 of the accumulation server 1. The processing illustrated in FIG.10 is started when an RTP packet is received by the accumulation unit11, for example.

In OP1, the accumulation unit 11 determines whether or not an RTP packetis lost, based on the sequence numbers of the TS packets included in thereceived RTP packet and the TS packets included in the immediatelypreceding RTP packet. In the case where loss of an RTP packet isdetected (OP1: YES), the process proceeds to OP2. In the case where lossof an RTP packet is not detected (OP1: NO), the process proceeds to OP3.

In OP2, since loss of an RTP packet is detected, the accumulation unit11 performs error correction. Additionally, in the first embodiment, theencoder 50 performs data transmission using a predetermined errorcorrection coding method, and the accumulation unit 11 may performrestoration of the lost packet according to this predetermined errorcorrection coding method. The error correction coding method is notlimited to a specific method, and any known method may be used.Additionally, for example, in the case where packets are lostfrequently, lost packets are possibly not restored by the errorcorrection in OP2. Next, the process proceeds to OP3.

In OP3, the accumulation unit 11 extracts TS packets from the receivedRTP packet, and adds the same in the file output buffer 11M. In the casewhere a lost packet is restored by the error correction in OP2, theaccumulation unit 11 also adds the TS packets extracted from therestored RTP packet to the file output buffer 11M. Next, the processproceeds to OP4.

In OP4, the accumulation unit 11 determines whether or not there is aspace in the file output buffer 11M. For example, a threshold is set forthe capacity of the file output buffer 11M, and when the capacity of thefile output buffer 11M is below the threshold, the accumulation unit 11determines that there is no space in the file output buffer 11M. Thethreshold for the capacity of the file output buffer 11M is set to avalue equal to or greater than 3000 bytes, for example. This is becausethe maximum length of an IP packet is 1500 bytes, and also because thepacket restored by the error correction in OP2 may be added to the fileoutput buffer 11M in addition to the received packet. Incidentally, thethreshold for the capacity of the file output buffer 11M may be freelyset by the administrator, and is not particularly limited.

In the case where there is a space in the file output buffer 11M (OP4:YES), the processing illustrated in FIG. 10 is ended. In the case wherethere is no space in the file output buffer 11M (OP4: NO), the processproceeds to OP5.

In OP5, the accumulation unit 11 adds the TS packets stored in the fileoutput buffer 11M to a latest video file in the file server 2. Forexample, in the case where the size of the latest video file is apredetermined time length, the accumulation unit 11 newly creates avideo file. Then, the process proceeds to OP6.

In OP6, the accumulation unit 11 creates hash data of the video file towhich the TS packets have been added in OP5. With respect to an existingvideo file, a process of overwriting the hash data corresponding to thevideo file is performed. With respect to a newly created video file, ahash data creation process is performed. Next, the process proceeds toOP7.

In OP7, the accumulation unit 11 creates an index file for the videofile to which the TS packets have been added in OP5. With respect to anexisting video file, a process of adding the TS information of the TSpackets added to the video file, to the index file corresponding to thevideo file is performed. With respect to a newly created video file, anindex file creation process is performed. Then, the processingillustrated in FIG. 10 is ended.

Additionally, the processing illustrated in FIG. 10 is merely anexample, and the order of execution of the processes may be changed asappropriate, or processes may be added or removed as appropriate. Forexample, the order of execution of processes in OP6 and OP7 may bereversed. Also, in the case where the encoder 50 performs datatransmission without performing the error correction code process, theprocesses in OP1 and OP2 do not have to be performed.

FIG. 11 is an example of a flow chart of processing by the intermediateprocessing unit 12 of the accumulation server 1. The flow chartillustrated in FIG. 11 may be performed for a latest video file at apredetermined cycle, or may be performed at the time of occurrence of apredetermined event. The execution cycle in the case where the flowchart in FIG. 11 is to be performed at a predetermined cycle takes avalue smaller than the upper limit time length of a video file. Also, apredetermined event to be the trigger for execution of the flow chart inFIG. 11 is creation of the next new video file after the upper limittime length of a video file is reached, for example.

In OP11, the intermediate processing unit 12 reads pieces of hash datawhich are comparison targets from corresponding file servers 2. Forexample, in the system in FIG. 2, both of the accumulation servers A andB read the hash data corresponding to files A and B. Next, the processproceeds to OP12.

In OP12, the intermediate processing unit 12 determines whether thepieces of hash data which are comparison targets coincide with eachother or not. In the case where the pieces of hash data which arecomparison targets coincide with each other (OP12: YES), the processingillustrated in FIG. 11 is ended. In the case where the pieces of hashdata which are comparison targets do not coincide with each other (OP12:NO), the process proceeds to OP13.

In OP13, since the pieces of hash data which are comparison targets donot coincide with each other, the intermediate processing unit 12determines that a complementing process is to be performed for the videodata that is managed by its owner device, and invokes the complementingprocessing unit 13. Then, the processing illustrated in FIG. 11 isended.

FIG. 12 is an example of a flow chart of processing by the complementingprocessing unit 13 of the accumulation server 1. The flow chartillustrated in FIG. 12 is started when the complementing processing unit13 is invoked by the intermediate processing unit 12. Additionally, forthe sake of convenience in the description, the flow chart illustratedin FIG. 12 is assumed to be performed by the accumulation server A inFIG. 2.

In OP21, the complementing processing unit 13 reads index files whichare comparison targets. The complementing processing unit 13 of theaccumulation server A reads the index files of the files A and B. Next,the process proceeds to OP22.

The processes from OP22 to OP28 are repeated for the number of TSpackets included in the video file which is the target of management ofthe accumulation server 1, that is, the file A, which is the target ofmanagement of the accumulation server A.

In OP22, the complementing processing unit 13 refers to the index fileof the file A, and determines whether the sequence number of a TS packetwhich is a processing target takes a value that is continuous from thesequence number of the immediately preceding TS packet in the file A. Inthe case where the sequence number of the TS packet which is theprocessing target takes a value that is continuous from the sequencenumber of the immediately preceding TS packet in the file A (OP22: NO),no packet loss is detected, and the process is started from OP22 for thenext TS packet in the file A.

In the case where the sequence number of the TS packet which is theprocessing target takes a value that is not continuous from the sequencenumber of the immediately preceding TS packet in the file A (OP22: YES),packet loss is detected, and the process proceeds to OP23.

In OP23, the complementing processing unit 13 specifies the sequencenumber which is lost, between the sequence number of the TS packet, inthe file A, which is the processing target, and the sequence number ofthe immediately preceding TS packet in the file A. In the following, thesequence number which is lost will be referred to as the lost sequencenumber. Additionally, in the case of packet loss during transmission, anRTP packet is lost, and thus a plurality of TS packets are lost.Accordingly, in OP23, the number of sequence numbers of the TS packetsincluded in the lost RTP packet is specified as the lost sequencenumber. Then, the process proceeds to OP24.

In OP24, the complementing processing unit 13 determines whether thelost sequence number in the file A is present in the index file of thefile B. In the case where the lost sequence number in the file A ispresent in the index file of the file B (OP24: YES), the processproceeds to OP25. In the case where the lost sequence number in the fileA is not present in the index file of the file B (OP24: NO), the videopacket of the lost sequence number in the file A specified in OP23 isnot complemented by the file B, and the process proceeds to OP22 for thenext TS packet in the file A.

In OP25, the complementing processing unit 13 acquires, from the file B,the TS packet corresponding to the lost sequence number in the file Aspecified in OP23. The position of the TS packet, in the file B,corresponding to the lost sequence number is acquired from the offset inthe corresponding TS information in the index file of the file B. Next,the process proceeds to OP26.

In OP26, the complementing processing unit 13 adds the TS packetacquired in OP25 in the processing buffer. Next, the process proceeds toOP27.

In OP27, the complementing processing unit 13 determines whether or notthere is a space in the processing buffer. For example, a threshold isset for the capacity of the processing buffer, and when the capacity ofthe processing buffer is below the threshold, the complementingprocessing unit 13 determines that there is no space in the processingbuffer. In the case where there is a space in the processing buffer(OP27: YES), the process proceeds to OP22 for the next TS packet in thefile A. In the case where there is no space in the processing buffer(OP27: NO) the process proceeds to OP28.

In OP28, the complementing processing unit 13 adds the TS packet storedin the processing buffer in the complementary file of the file A in thefile server A. Then, the process proceeds to OP22 for the next TS packetin the file A.

FIGS. 13A and 13B are examples of a flow chart of processing by thedelivery processing unit 14 of the accumulation server 1. The flowcharts illustrated in FIG. 13A is started when a delivery requestincluding specification of a reproduction start time is received by theaccumulation server 1. In the following, the specified reproductionstart time included in the delivery request will be referred to as aspecified time.

In OP31, the delivery processing unit 14 reads an index filecorresponding to a video file which is a delivery target. Additionally,information at least about the time of recording start of the video dataincluded in the video file is held as metadata, and the video file whichis the delivery target may be specified based on the specified time andthe information about the time of recording start of the video data.Next, the process proceeds to OP32.

In OP32, the delivery processing unit 14 specifies the read position, inthe video file which is the delivery target, corresponding to thespecified time, based on the TS time in the index file corresponding tothe video file. The TS time indicates the reproduction start time of aTS packet from the beginning of the video file. The delivery processingunit 14 specifies, as the read position, the offset of a TS packet forwhich the time length of the difference between the specified time andthe start time of the video file, and the value of the TS time in theindex file match or approximately match each other. Next, the processproceeds to OP33.

In OP33, the delivery processing unit 14 determines whether data at thespecified time is present at the read position, in the video file,specified in OP32. This determination is performed based on thetimestamps of TS packets in the index file of the video file. In thecase where there is a TS packet having the timestamp of the specifiedtime in the video file (OP33: YES), the delivery processing unit 14acquires the TS packet, and the process proceeds to OP36. In the casewhere a TS packet having the timestamp of the specified time is notpresent in the video file (OP33: NO), the process proceeds to OP34.

In OP34, since a TS packet having the timestamp of the specified time isnot present in the video file, the delivery processing unit 14 refers tothe complementary file corresponding to the video file, and determineswhether a TS packet having the timestamp of the specified time ispresent in the complementary file. In the case where a TS packet havingthe timestamp of the specified time is present in the complementary file(OP34: YES), the delivery processing unit 14 acquires the TS packet fromthe complementary file, and the process proceeds to OP36. In the casewhere a TS packet having the timestamp of the specified time is notpresent in the complementary file (OP34: NO), the process proceeds toOP35.

In OP35, the delivery processing unit 14 determines whether there is, inthe video file, a TS packet corresponding to the time immediately afterthe specified time. In the case where a TS packet corresponding to thetime immediately after the specified time is not present in the videofile (OP35: NO), the process returns to OP34, and the deliveryprocessing unit 14 refers to the complementary file. In the case where aTS packet corresponding to the time immediately after the specified timeis present in the video file (OP35: YES), the delivery processing unit14 acquires the TS packet, and the process proceeds to OP36.

In OP36, the delivery processing unit 14 outputs the acquired TS packetto a transmission buffer. The transmission buffer is a FIFO (First InFirst Out) queue that is created in the main storage device 102. Next,the process proceeds to OP37.

OP37 to OP39 are processes that are repeated for a TS packet having asequence number immediately after that of the TS packet that is outputto the transmission buffer in OP36, and following TS packets.

In OP37, the delivery processing unit 14 determines whether there isdata of the corresponding sequence number in the video file. Thisdetermination is performed based on the sequence number in the header ofthe TS packet in the video file. In the case where a TS packet of thecorresponding sequence number is present in the video file (OP37: YES),the delivery processing unit 14 acquires the TS packet, and the processproceeds to OP39. In the case where a TS packet of the correspondingsequence number is not present in the video file (OP37: NO), the processproceeds to OP38.

In OP38, since a TS packet of the corresponding sequence number is notpresent in the video file, the delivery processing unit 14 refers to thecomplementary file corresponding to the video file, and determineswhether a TS packet of the corresponding sequence number is present ornot. In the case where a TS packet of the corresponding sequence numberis present in the complementary file (OP38: YES), the deliveryprocessing unit 14 acquires the TS packet from the complementary file,and the process proceeds to OP39. In the case where a TS packet of thecorresponding sequence number is not present in the complementary file(OP38: NO), the process proceeds to OP37, and the process is performedfor the TS packet of the sequence number immediately after thecorresponding sequence number.

In OP39, the delivery processing unit 14 outputs the acquired TS packetto the transmission buffer. The process proceeds to OP37, and theprocess is performed for the TS packet of the sequence numberimmediately after the corresponding sequence number. The processes fromOP37 to OP39 are repeated until a delivery stop request is received fromthe delivery request source.

The processes in FIGS. 13A and 13B are processes for outputting a TSpacket to the transmission buffer. The delivery processing unit 14 alsoperforms processes for reading a TS packet from the transmission buffer,and for transmitting the same to a delivery request source. In theprocesses for reading a TS packet from the transmission buffer, and fortransmitting the same to a delivery request source, the deliveryprocessing unit 14 sequentially transmits TS packets based on thetimestamps in the index file, according to the data transmissiontimings.

FIG. 14 is an example of a flow chart of processing by the deletionprocessing unit 15 of the accumulation server 1. The processingillustrated in FIG. 14 is performed at a predetermined cycle, forexample. The predetermined cycle is once an hour or once a day, forexample, and is freely set by the administrator.

Additionally, the processing illustrated in FIG. 14 is processing thatis performed by the accumulation server 1 that is set as a master. InFIG. 14, the files A and B in FIG. 2 are described as deletion targetsfor the sake of convenience in the description. Additionally, a videofile for which there is a redundant file at the time of start ofexecution of the processing in FIG. 14 is to be taken as the deletiontarget. However, a latest file which has not reached the upper limittime length is eliminated from the deletion target.

In OP41, the deletion processing unit 15 reads the index files of thefiles A and B which are deletion targets. Then, the process proceeds toOP42.

In OP42, the deletion processing unit 15 calculates the number of lostpackets for each of the files A and B, based on the sequence numbers inthe respective index files. Next, the process proceeds to OP43.

In OP43, the deletion processing unit 15 determines whether the numbersof lost packets coincide with each other between the files A and B. Inthe case where the numbers of lost packet coincide with each otherbetween the files A and B (OP43: YES), the process proceeds to OP46. Inthe case where the numbers of lost packets are different between thefiles A and B (OP43: NO), the process proceeds to OP44.

OP44 and OP45 are processes for a case where the numbers of lost packetsare different between the files A and B. In OP44, the deletionprocessing unit 15 calculates, for each of the files A and B, the numberof times of occurrence of continuous lost TS packets. Next, the processproceeds to OP45.

In OP45, the deletion processing unit 15 marks, as the deletion targets,the video file of a greater number of times of occurrence of continuouslost TS packets and the complementary file of the video file. This isbecause, in the first embodiment, the video quality is assumed to bereduced as the number of times of occurrence of continuous lost TSpackets becomes greater. That is, the deletion processing unit 15 keepsthe file with higher video quality. Next, the process proceeds to OP47.

In OP46, since the numbers of lost packets coincide with each otherbetween the files A and B, the video file managed by the owner device,which is the master, and the complementary file of the video file aremarked as the deletion targets. Then, the process proceeds to OP47.

In OP47, the deletion processing unit 15 checks the disk usage rate, andin the case where the size of an access queue, which is a queue waitingfor access to the file server 2 storing files, falls to or below apredetermined threshold, the deletion processing unit 15 deletes themarked files. Then, the processing illustrated in FIG. 14 is ended.

<Effects of First Embodiment>

In the first embodiment, for example, the accumulation server A acquiresa lost packet of the file A from the file B, which is a redundant fileof the file A, and creates a complementary file for the file A. In thesame manner, the accumulation server B acquires a lost packet of thefile B from the file A, and creates a complementary file for the file B.Accordingly, the number of lost packets may be reduced and data ofhigher video quality may be achieved for both the files A and B, and theinfluence of packet loss during transmission may be reduced. Reliabilityof the video data may thus be increased.

Also, the accumulation server 1 creates a complementary file separatelyfrom the video file instead of inserting, into the portion of the lostpacket of the video file, a video packet, corresponding to a lostpacket, acquired from another video file. Accordingly, an increase inthe processing load on the accumulation server 1 may be suppressed.

In the first embodiment, the complementing processing unit 13 is invokedand its operation is started when hash data of a video file and hashdata of another video file which is a redundant file do not coincidewith each other. Therefore, in the case where pieces of hash data of twofiles coincide with each other, the complementing processing unit 13does not operate, and operation of the complementing processing unit 13may be further reduced, and the processing load on the accumulationserver 1 may be suppressed.

Also, in the first embodiment, the amount of storage used for storingvideo files may be reduced by the accumulation server 1 set as themaster deleting redundant video files.

Furthermore, in the first embodiment, the accumulation server 1 set asthe master deletes redundant files when the size of an access queueaccording to the disk usage rate is at or below a threshold, and thusinfluence on other processes by deletion of files may be suppressed.

According to one aspect, reduction in the quality of video data due to apacket loss during transmission of the video data may be suppressed.

<Others>

In the first embodiment, the encoder 50 encodes video data by MPEG, butthis is not restrictive, and video compression standards that use TSpackets, such as H265 and H264 may also be used instead of MPEG.

In the first embodiment, lost packets are complemented on a per TSpacket basis, but this is not restrictive, and lost packets may also becomplemented on a per RTP packet basis. In the case where lost packetsare to be complemented on a per RTP basis, the index file includes RTPinformation about an RTP packet instead of the TS information, which isinformation about a TS packet. Like the TS information, the RTPinformation includes a reproduction start time from the beginning of avideo file, a sequence number, offset position information, a timestampand the like. In this case, the RTP packet is an example of a “videopacket”.

In the first embodiment, a system is described where a redundantconfiguration is achieved by two accumulation servers A and B, but thetechnology described in the first embodiment may also be applied to asystem where the redundant configuration is achieved by three or moreaccumulation servers. In the case where the technology described in thefirst embodiment is applied to a system where the redundantconfiguration is achieved by three or more accumulation servers, thefollowing will be true.

In the processing by the intermediate processing unit 12 illustrated inFIG. 11, the number of pieces of hash data which are comparison targetsis made three or more. In OP12 in FIG. 11, the complementing processingunit 13 is invoked if there is even one piece of hash data that does notcoincide among the three or more pieces of hash data which arecomparison targets.

Also, when assuming a case where there are accumulation servers A, B andC, and where the servers manage respective files A, B and C, thefollowing will be true for the processing by the complementingprocessing unit 13 in FIG. 12. The accumulation server A determineswhether a lost packet of the file A is present in the file B or the fileC. In the case where the lost packet of the file A is present in boththe file B and the file C, a TS packet corresponding to the lost packetis acquired from the file with a smaller number of times of occurrenceof continuous lost packets. In the case where the lost packet of thefile A is present in one of the files B and C, a TS packet correspondingto the lost packet is acquired from the file having the lost packet ofthe file A.

Also, the accumulation server A may successively perform the processingin FIG. 12 for combinations of the file A and the file B, and the file Aand the file C. For example, the accumulation server A acquires a lostpacket of the file A from the file B by the first execution of theprocessing in FIG. 12, and acquires by the second execution of theprocessing in FIG. 12, from the file C, a lost packet of the file Awhich was not acquired from the file B.

In the first embodiment, the accumulation server 1 performs theprocessing by the accumulation unit 11, the intermediate processing unit12, the complementing processing unit 13, the delivery processing unit14, and the deletion processing unit 15. However, this is notrestrictive, and the processing by the accumulation unit 11, theintermediate processing unit 12, the complementing processing unit 13,the delivery processing unit 14, and the deletion processing unit 15 mayalternatively be performed by different servers. That is, the video dataaccumulation system may include an accumulation server, an intermediateprocessing server, a complementing processing server, a delivery server,and a deletion processing server corresponding respectively to theaccumulation unit 11, the intermediate processing unit 12, thecomplementing processing unit 13, the delivery processing unit 14, andthe deletion processing unit 15.

<Recording Medium>

A program for causing a computer and other machines and devices(hereinafter “computer or the like”) to achieve any of the functionsdescribed above may be recorded in a recording medium that can be readby the computer or the like. The function may be provided by causing thecomputer or the like to read and execute the program in the recordingmedium.

Here, the recording medium that can be read by a computer or the like isa non-transitory recording medium that is capable of accumulatinginformation such as data and programs electrically, magnetically,optically, mechanically or chemically, and that can be read by acomputer or the like. Of such recording media, those that can bedetached from the computer or the like include a flexible disk, amagneto-optical disk, a CD-ROM, a CD-R/W, a DVD, a Blu-ray disk, a DAT,an 8-mm tape, and a memory card such as a flash memory, for example.Also, recording media fixed to the computer or the like include a harddisk, a ROM (Read Only Memory), and the like. Moreover, an SSD (SolidState Drive) may be used as a recording medium that can be detached fromthe computer or the like, or as a recording medium that is fixed to thecomputer or the like.

All examples and conditional language provided herein are intended forthe pedagogical purposes of aiding the reader in understanding theinvention and the concepts contributed by the inventor to further theart, and are to be construed as limitations to such specifically recitedexamples and conditions, nor does the organization of such examples inthe specification relate to a showing of the superiority and inferiorityof the invention. Although one or more embodiments of the presentinvention have been described in detail, it should be understood thatthe various changes, substitutions, and alterations could be made heretowithout departing from the spirit and scope of the invention.

What is claimed is:
 1. A video data processing apparatus comprising: aprocesser configured to execute a process including: creating a fileincluding video packets received from a video source; creating an indexfile including a sequence number and offset position information,indicating a position in the created file, of each of the video packetsincluded in the created file; and creating that creates, when there is aloss of a video packet in the created file, complementary data forcomplementing the loss of the video packet, based on the index file ofthe created file and an index file of another file including videopackets received from the video source by a path different from a pathof the video packets included in the created file.
 2. The video dataprocessing apparatus according to claim 1, the process furthercomprising: creating hash data based on the created file; and comparingpieces of hash data of the created file and the another file, whereinthe complementary data is created when the pieces of hash data do notcoincide with each other.
 3. The video data processing apparatusaccording to claim 1, the complementary data is held as a file that isdifferent from the created file.
 4. The video data processing apparatusaccording to claim 1, the process further comprising reading a videopacket from the created file, that reads a lost video packet of thecreated file from the complementary data, and that transmits the readvideo packet to a predetermined destination.
 5. The video dataprocessing apparatus according to claim 4, wherein each of the videopackets includes a timestamp representing a time of creation, whereinthe index file also including a timestamp of each of the video packets,and wherein based on the index file, a position of a video packet isspecified, in the created file, corresponding to a time specified in adelivery request, and transmission is performed from a video packet ofthe specified position.
 6. The video data processing apparatus accordingto claim 1, the process further comprising deleting a file of poorervideo quality between the created file and the another file.
 7. Thevideo data processing apparatus according to claim 6, wherein from theindex files, a number of times of occurrence of continuous lost videopackets of each of the created file and the another file are calculates,and a file of a greater number of times of occurrence of continuous lostvideo packets is deleted as the file of poorer video quality.
 8. Thevideo data processing apparatus according to claim 1, wherein the videopackets are transmitted by using UDP.
 9. The video data processingapparatus according to claim 1, wherein the video packets are created byencoding, by a predetermined video compression or expansion method,video data acquired by a video source.
 10. A video data processingsystem comprising: a first processer configured to execute a processcreating a file including video packets received from a video source; asecond processer configured to execute a process creating an index fileincluding a sequence number and offset position information, indicatinga position in the created file, of each of the video packets included inthe created file; and a third processer configured to execute a processcreating, when there is a loss of a video packet in the created file,complementary data for complementing the loss of the video packet, basedon the index file of the created file and an index file of another fileincluding video packets received from the video source by a pathdifferent from a path of the video packets included in the created file.11. A video data processing method to be performed by a computer, thevideo data processing method comprising: creating a file including videopackets received from a video source; creating an index file including asequence number and offset position information, indicating a positionin the created file, of each of the video packets included in thecreated file; and creating, when there is a loss of a video packet inthe created file, complementary data for complementing the loss of thevideo packet, based on the index file of the created file and an indexfile of another file including video packets received from the videosource by a path different from a path of the video packets included inthe created file.
 12. A non-transitory computer-readable recordingmedium recording a video data processing program that causes a computerto execute: creating a file including video packets received from avideo source; creating an index file including a sequence number andoffset position information, indicating a position in the created file,of each of the video packets included in the created file; and creating,when there is a loss of a video packet in the created file,complementary data for complementing the loss of the video packet, basedon the index file of the created file and an index file of another fileincluding video packets received from the video source by a pathdifferent from a path of the video packets included in the created file.